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INVENTION DISCLOSURE 



1 Title of the Invention 

Advanced Performance Management of Mobile Data Networks 

2 Background 

2.1 Technical Background/Existing Technology 

The performance management of cellular mobile data networks (GPRS, 
UMTS, CDMA2000) gets more and more important as the number of 
subscribers starts to pick up, the traffic on these networks increases and 
subscribers start to use more and more different applications and services. 
There is a need for performance management solutions, which makes it easy 
to find out when there is a performance probfem in the network, but it has the 
same importance to find out the location of the performance problem. Such a 
performance management system should help the operator in the following 
areas: 

Performance analysis (Do users get what they paid for or what they 
expect?) 

- Bottleneck analysis (What are the bottlenecks in the network?) 

- System improvement (After identifying the causes of performance 
problems, try to enhance the system such that these problems get 
eliminated.) 

- Dimensioning (Which cells, finks, etc need to be re-dimensioned, and 
how?) 

- Etc. 

In case of a circuit switched service (such as e.g., voice), it was basically 
enough to measure the call intensities, call durations and the ratio of blocked 
calls. In case of packet switched services (e.g. Web, WAP, FTP, e-mail, 
MMS ? etc.) the above tasks are not at all trivial, because the end-to-end (or 
user perceived) performance depends on the interaction of many protocols at 
different interfaces and on various protocol layers. Furthermore, the use of 
shared resources leads to rather complicated queuing phenomena, which are 
difficult to model and analyze. 
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In current GSM, GPRS, CDMA2000 and UMTS networks, the service area is 
divided into cells covering limited geographical areas. The aim of the mobile 
operator should be to provide a constant and ubiquitous high quality service 
regardless of the location of its subscribers. This is a very challenging task for 
example because subscribers tend to be distributed non-homogenously 
across the service area, 

2.1.1 Determining User Perceived Quality using Passive Monitoring in Packet 
Switched Systems 

Passive measurement based characterization of IP [TCPIoss] as well as 
GPRS networks has already been carried out 

For example, in case of GPRS [GPRS_meas] packets on the Gi interface 
have been captured. The Gi interface connects the Gateway GPRS Support J \ 
Node (GGSN) with external packet data networks (such as e.g., an ISP). 
Based on the Gi traffic traces detailed traffic and end-to-end performance 
analysis results has been delivered to operators. At the same measurement 
point where Gi traffic can be captured, the messages to/from the RADIUS 
server can typically also be captured The RADIUS packets can be used to 
reconstruct user sessions. 

2.1 .2 Performance Counters for GSM/GPRS ceils 



Statistics and Traffic Measurement Subsystem in the Ericsson BSS records 
some key radio network events [STS,STS9.1]. These counters provide 
information about the performance and traffic load in specific cells. The 
following list exemplifies what sort of information the operator can obtain from 
these counters: 

1 . The number of connections successfully established on the TCH. ( ) 

2. For every cell there are counters for the number of allocation 
attempts. They are incremented at every attempt to allocate a TCH in 
a resource type in the cell, to be used for signalling, data or speech, 
regardless of whether the allocation succeeded or failed. ( ) 

3. A counter shows the accumulated number of available (i.e. idle and 
busy) Basic Physical Channels used for traffic in a cell. 

4. Number of Offered incoming Calls. 



5. Number of Offered Normal Originating Calls. 

6. A counter is stepped each time the BSC attempts to allocate a set of 
one or more PDCHs from the circuit switched domain. 

7. Accumulated number of allocated PDCHs. 

8. The peak number of active PDCHs from the last 1 5 minutes. 
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9, The total number of RLC data blocks transmitted by the PCU during 
the measurement period. 



10. The total number of RLC data blocks retransmitted by the PCU during 
the measurement period. 

11. Accumulated number of TBFs per traffic combination of UL/DL 

12. Accumulated number of PDCHs carrying at least one TBF per traffic 
combination of UL/DL and GPRS/EGPRS. 

Counters are collected every 5 or 15 minutes. This is the Basic Recording 
Period, which can be set by command and is recommended to be 15 
minutes. Measurement data for the Basic Recording Period is accessible in 
the database for two hours, 

2.1.3 Drive Tests 

In this set-up, special purpose terminals are used, which run a given 
application. The terminal is operated by a test user and it runs an application, 
which is under test. 

In case of cellular mobile data networks, the terminal can for example be 
installed on the board of public transport service bus or a taxi. The application 
is run repeatedly, and the performance results together with the cell level 
location of the test are recorded. This way performance results are obtained 
for the cells, which have been visited during the drive test. 

2.2 Problems with existing solutions 

In order to efficiently monitor and manage cellular mobile data networks, two 
type of information is necessary: 

1 . User perceived end-to-end performance of different applications 

2. Information about the resource usage and performance in the 
different cells 

The need for the first type of information is obvious, the reason for requiring 
this information on cell level is that cells are the basic dimensioning units of 
cellular data networks, congestion typically occurs because the resources of 
a particular cell are exhausted, and the performance problem can most often 
be alleviated by adding additional resources (e.g. a couple of new traffic 
channels) to the problematic cell. 

As mentioned in the previous sections, advanced passive measurement 
based methods are available to characterize the user perceived end-to-end 
performance of different applications in case of GPRS networks, but these 
methods currently work on a whole network basis and it is not currently 
possible to obtain the key performance indicators on cell leveL 
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The problem with the monitoring systems developed for the Internet is that 
they miss an important abstraction level, which is key to a mobile operator, 
and that is the level of the mobile subscriber. IP addresses (and IP 
application transactions) need to be associated with the mobile subscriber 
they belong to, which can not be done with a traditional IP network monitoring 
system. 

There is a set of counters available in the Ericsson BSS to obtain 
performance results on cell level. It is clear from the above list that these 
counters can be used to understand the cell level performance of circuit 
switched services but they does not tell much about the user perceived end- 
to-end quality of service of packet switched applications and services. 

Other problem with the counters is that other system vendors might 
implement other counters, which makes it impossible to build a coherent >, 
performance monitoring system in a multivendor network, Furthermore, the 
maintenance of these counters puts a significant load on the BSC node, 
therefore performance results are available only with a very coarse grained 
time resolution. 

Most important problem with the third performance monitoring alternative, the 
drive test is that it is not scalable. It generates additional load over the 
network and it requires significant time to cover a large area with enough 
measurements to allow obtaining statistically reliable measurement results, 
not to mention the difficulty of generating realistic application level traffic 
patterns in such an artificial use case. 

To summarise, we miss a passive performance monitoring solution, which 

1 . provides information about the true, user perceived end to end 
performance of mobile data networks, ( ) 

2. it provides this information on cell level, 

3. it is scalable, and 

( .) 

A, it is vendor independent 

To build such a passive performance monitoring system for cellular data 
networks is not trivial because the information, which is necessary to be 
collected, can not be obtained at a single measurement point. 
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3 Basic Concept 

This invention disclosure outlines a sofution, which meet all of these four 
criteria identified above. A method and a system is presented, which enables 
efficient and detailed characterization and performance management of 
particular cells in a cellular mobile data network. A set of key performance 
indicators which describe the true, user perceived end to end quality of the 
most commonly used applications are also listed. Such a method greatly 
improves the performance and service management of cellular mobile data 
networks, given that the operator can easily find out if the performance of a 
ceil does not meet the user's expectations and can immediately act where the 
problem is. The key element of the system is to build a traffic and session 
database by correlating traffic and mobility information extracted from 
passively captured traces, which can be collected from multiple standardized 
interfaces. 

Keywords: correlating information from multiple network traces, 
reconstructing user sessions, building a condensed traffic database, passive 
monitoring, cell level key performance indicators 

4 Detailed description 

4.1 Detailed Technical Description of the Invention 

4.1.1 The solution 

The method is composed of four main steps: 

1 . Capturing raw traffic traces over standardized interfaces of an 
operational cellular mobile data network 

2. Parsing through the traces in order to extract and correlate all the 
information, which is. needed to build a traffic database. This traffic 
database contains information about each and every user session and 
user transaction which happened during the measurement period 

3. Defining a set of appropriate key performance indicators, which can 
be used to characterize the performance of cells in terms of user 
perceived quality of service parameters 

A. Calculating the above defined key performance indicators by selecting 
an appropriate subset of the transactions in the traffic database, and 
calculating the key performance indicator value by 
summing/averaging the given QoS measure of the selected individual 
transactions. 
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4.1 .1 .1 Step 1 : Capturing the traffic traces 

The first step is to look at the architecture of the cellular mobile packet data 
network and to look at the protocol stacks over the standardized interfaces. 
The result of this investigation is a set of interfaces, which need to be 
captured in order to have all the information necessary for the traffic database 
available. Al! the IP packets of all (or at least a significant portion to ensure 
statistical reliability of the results) of the user transactions need to be 
captured together with the session and mobility management signaling of the 
users. If the above information needs to be captured at multiple interfaces, it 
is required to have at least one unambiguous identifier of the user present in 
all the traces. An additional requirement is to record a timestamp with each 
captured packet. 

AAA. 2 Step 2: Building the traffic database 

The second step is to build the traffic database. The process is depicted in 
Figure 1 . IP packets from the captured traces are processed one by one and 
the packets belonging to the same application transaction of the same user 
are grouped together. These groups can be created by looking at the <source 
IP address, destination IP address, source port, destination port> fields in the 
IP header. Applications can be identified by looking for the standard port - 
numbers/ (E.g:: TCP port 80 for Web traffic.) Depending on the application; f-:* 
• Ibg ic, : identified packet groups can be further divided into user transactions^ 
like TCP connections, HTTP object downloads, WAP object downloads, and 
so on. After having alf packets of a particular transaction collected, 
condensed information like the start, end, duration, amount of data in uplink 
and downlink, success, failure of the transaction is generated. 

Further difficulty is to associate subscribers with the condensed application 
transactions information collected above, in mobile packet data networks 
there are signaling messages to initiate a subscriber data session. In these 
signaling exchanges, a subscriber identifies itself by one of its unique 
identifier in the mobile system (for example its Internationa! Mobile Subscriber 
Identity) and the system answers with an IP address, which the mobile can 
use for its application transactions. By parsing through these signaling V 
messages, the required association between subscribers and their 
transactions can be established. The Quality of Service parameters 
requested for the subscriber data session can also be extracted from the 
signaling messages. 

The only missing link now is the association between the user transaction and 
its cell level location. In mobile data networks, typically when there is an 
active user data session and typically at interfaces in the radio access 
network of the system, there is signaling when the mobile changes cell. In 
these signaling messages a (sometimes temporary but unique) identifier of 
the subscriber is sent together with its new cell level location. If the identifier 
in these signalling exchanges is temporary, then the signaling exchange in 
which the subscriber identified with a permanent unique identifier gets its 
temporary unique identifier needs also to be interpreted. This results in a 
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database containing the permanently unique identifier of the subscriber 
together with cells it visited, and the timestamp when the visit happened. 
Using this data, the condensed transaction information is extended with the 
cell level location of the transaction and an indicator of cell change during the 
course of the transaction. Finally, summary data (type and number of 
transactions, total number of uplink and downlink traffic, Quality of Service 
profile) is generated about the transactions belonging into the same user 
session, and it is stored together with the list of cells visited during the 
session and the timestamp of the visits. 
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Figure 1. Building the traffic database 



4.1.1.3 



Step 3: Defining the Key Performance Indicators 



The following key performance indicators are used to characterize the 
performance of a cell in mobile packet data networks: 
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MMS large message download/send rate in a specified cell 

Given in bit/sec, these KPIs define the average transmission rate during 
sending or downloading of large MMS messages. Only successful 
transactions are considered whose size is larger than a given amount of 
bytes. Recommended value is 5 kbytes. The rate is calculated as the total IP- 
layer transmitted/received bytes divided by the total duration of the 
transaction. A size limit is included to eliminate transient effects of short 
messages. 



WAP object download delay in a specified cell 

The average delay between the request packet from the mobile until the 
server response is successfully acknowledged by the mobile. Precondition: 
successfully finished download. \ 

Web small object download time (9-11 kbyte) in a specified cell 

The average time it takes to download a small HTTP object. Only small (9-1 1 
Kbytes) files are measured. Due to the TCP protocol, small objects are not 
able to utilize the full capacity available in the cell. The download time of such 
small objects depends more on the round-trip time. To have comparable 
results between different measurements and cells, only objects that fall into a v 
narrow range' are measured. The chosen range of 9-1 1 kbytes was chosen 
because the median of Web downloads falls in this range. Condition: object 
download was successful. 

Web large object download rate (larger than SOkbyte) in a specified cell 

The average rate is the size of the object divided by the time it takes to 
successfully download the object. This measure is also called goodput Only ( ) 
large objects are measured, when the available end-to-end path capacity 
dominates the measure and not the object size. Condition: object download 
was successful. 

FTP download rate (larger than SOkbyte in a specified cell) ( 

The average rate is the size of the downloaded file divided by the time it 
takes to download it. Only large files are measured, when the available end- 
to-end path capacity dominates the measure and not the file size. Condition: 
file download was successful. 

POP3, mail download time (9-11 kbyte) in a specified cell 

This KPI defines the average time to successfully download one or more e- 
mails from the POP3 e-mail server. The whole time is measured including 
server greeting, authentication, and time to download of all mails and quit. 
Condition: mail download was successful, and the total downloaded amount 
of bytes is small (between 9-1 1 kbytes). 





Date: 



Read and Understood by: 



Date: 



ERICSSON ^ 



CONFIDENTIAL 



Prepared (also subject responsible if other) 

ETH/RT Szabo, Borsos, Veres, Mafomsoky 


Document Nr. 

1/ETH/RL-2003:0133 


Approved ] Checked 

ETH/RTC Hans Eriksson 


Date | Rev 

2003-08-28 A 


P-N umber 



4.1,1.4 



POP3, mail download rate (larger than SOkbyte) in a specified cell 

This KPI defines the average rate during successful download of one or more 
e-maiis from the POP3 e-rnail server. The rate is measured during the whole 
time including server greeting, authentication, and time to download of all 
mails and quit Condition: maH download was successful, and more than 
50kbytes was downloaded. 

End-to-end achievable throughput in a specified cell 

This KPI measures the average achievable IP layer throughput end-to-end. 
This KPf is measured by tracing those mobiles that generate one or more 
parallel TCP downloads saturating the downlink channel. In an optimally 
configured network this KPI shows the available data transfer capacity in the 
cell. 

Rate of TCP Connections, Stalled Periods in a specified cell 

This KPI gives the average rate achieved by greedy TCP flows, as well as the 
frequency of stalled periods within them. 

User-Perceived Throughput History in a specified cell 

This KPI gives the throughput limitation users perceive as a function of time. . 
It can be used for Service Level Agreement validation. It is based on the 
throughput of greedy user session segments. Optionally, the variance and 
quantiles can also be given. 

in addition to these values, it is necessary to determine the share of different 
traffic types in the cells. This means calculating the accumulated traffic of the 
flowing protocols: TCP, UDP, ICMP, HTTP, FTP, WAP, SMTP, DNS, POP3, 
IMAP4, and Telnet. 

Using the information captured in the traffic database described in 4.1.1.2 
additional key performance indicators can be defined. 

Step 4: Obtaining the Key Performance Indicators 

The procedure for calculating the above listed key performance indicators is 
as follows: 

1 . Read the next transaction record from the traffic database. 

2. Check whether this transaction is of the type, which the KPI is about. This 
can be done using the flow type field of the transaction record, 

3. Check whether the transaction happened in the cell specified for the KPi. 
This can be done using the Cell Id field of the transaction record. 
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4. Calculate the quantity defined by the KPI for the particular transaction. 
Information elements used are: duration, timestamp of the first data 
packet, timestamp of the last data packet, packet count and loss count 
fields of the transaction record. 

5. Add the value to an aggregation counter, and increase the counter 
calculating the number of eligible transactions for the KPI. 

6. Go back to step 1 until all the transactions are processed. 

7. Calculate the KPI value by dividing the value of the aggregation counter 
with count of the eligible transactions. 

4.1,2 A preferred embodiment of the solution in GPRS networks 

4.1 ,2.1 Capturing of the raw traffic traces 

In the specific case of GPRS networks, the following interfaces provide data, 
which is useful when building the traffic database. Depending on the 
configuration of the particular network, simultaneously captured traffic traces 
are needed for the method to operate from one or more of the below listed 
interfaces. See Section 4.1 .2.2 for processing details in case of different trace 
combinations. 

Gb interface interconnects the BSS with the SGSN. It carries GPRS Mobility 
Management and GPRS Session Management signaling together with the 
data packets of the users. It is a Frame Relay interface, but many protocol 
analyzers (Nettest, Radcom, Nethawk, Tektronix) are available on the market 
to capture all traffic from one or more Gb interfaces into a dump file. 

Gn interface interconnects the GPRS Support Nodes (SGSNs and GGSNs). ( 
It carries GPRS Session Management signaling together with user data 
packets. Both data and signaling packets are transported over GPRS 
Tunneling Protocol (GTP). This interface is typically a standard IP (Ethernet) 
interface so freeware tools like TCPDump can be used to capture traffic from 
the Gn interface into a dump file, ( 

Gi interface interconnects the GPRS network (GGSN) with an external IP 
network. This interface is typically a standard IP (Ethernet) interface so 
freeware tools like TCPDump can be used to capture traffic from the Gi 
interface into a dump fife. In order to be able to track PDP sessions, RADIUS 
messages are also need to be captured in addition to the user data packets, 

Gr interconnects the SGSN with the HLR. Many protocol analyzers (Nettest, 
Radcom, Nethawk, Tektronix) are available on the market to capture traffic 
from Gr interfaces into a dump file. 
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4.1 .2.2 Building the traffic database 



Building the traffic database from a Gb trace 

The following information can be extracted from protocol data units captured 
over the Gb interface [BSSGP]: 

Ceil ID of each and every active user BSSGP UL-UNITDATA PDU 
transfers an MS's LLC-PDU and its associated radio interface information 
across the Gb-interface. Part of this PDU is the Ceil ID. 

GPRS Multi Slot Class: The purpose of the Mobile Station Classmark 4 
information element is to provide the network with information concerning 
aspects of the mobile station related to GPRS. Among many other things this 
information element contains data about the GPRS Multi Slot Class. Mobile 
Station Classmark 4 information eiement is present in Attach Request 
messages. Another information element MS Radio Access Capability also 
contains the GPRS muiticlass information. This information element is 
present in DL-UNiTDATA. 

The relationship between the different information elements available in the 
Gb trace, the required processing steps and the resulting databases are 
depicted in Figure 2. 
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Figure 2. Building the GPRS Traffic Database from a Gb Trace 

BSSGP DOWNLINK UNITDATA PDU contains IMS! and MS Radio Access 
Capability, together with the TLLI, and the old TLLl whenever TLLI changes, 
BSSGP UPLINK UNITDATA PDU carries the TLLI and the Cell ID. The 
following algorithm can be used to extract the mobility data: 

1 . Whenever a DOWNLINK UNITDATA PDU is encountered in the trace, 
check whether it contains a new IMS! 
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• If a new IMS! is encountered register it, together with the corresponding 
TLLI and timestamp. 

• If an already known IMSI is encountered, check whether TLLI change 
is indicated. 



• If TLLI change is indicated, register the new TLLI as belonging to the 
ofd IMSI 

2. Whenever an UPLINK UNITDATA PDU is encountered in the trace, 
look up the IMSI database mentioned above to find out the IMSI which the 
TLLI belongs to. 

3. Check whether the Ceil ID is identical to the last one registered to the 
IMSI in the database. 



• If a new Cell ID is found, register it to the IMSI together with the 
timestamp of the BSSGP PDU. 

Whenever an IP packet carrying user data is found in the BSSGP packet, it is 
used for reconstructing the user transactions. A transaction is coherent traffic 
between two endpoints, identified by IP address and ports (only for TCP and 
UDP). The delimitation of transactions is protocol-specific, for example, it is a ; 
connection in case of TCP, it is a request/response pair in case of a DNS - 
query. Whenever packets of a new transaction are collected from the packet 
stream, a new record is created containing the following information: 

The timestamp of transaction start; 

Flow type, Inner and outer addresses; Inner and outer ports; 
Protocol number; 

Numeric identifier of the user session; 
Transaction duration in seconds from start to last activity; 
Number of packets in and out; Number of bytes in and out; 
IP layer rates in both directions (bits per second); 
Protocol-dependent statistics. 
IMSI of the user; 

Cell Id at the start of the transaction, 

Flag whether the user has changed cell during the transaction 
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• MS Class of the terminal; 

Parallel with above described processing of the BSSGP header and user IP 
packets, the PDP session management signaling contained in the BSSGP 
packets is also processed. Based on the Create PDP Context Request 
Create PDP Context Response signaling messages and the condensed 
transaction records, PDP session records are created which store the 
following information about the new PDP session: 

• Starting timestamp; addresses and port numbers; 

• Numeric identifier referenced from the user transactions database; 

• Duration; Number of transactions involved; 

• Number of packets and bytes transmitted for both directions; 

• Number of transactions on different network and application protocols. 

• IMSl of the user 

• IP address allocated for the session 

• QoS profile r v 

• List of {Cellld, Timestamp} pairs tracking the mobility of the user during 
the session 

Building the traffic database from an encrypted Gb and Gr trace 

Operators often encrypt their Gb interface, which hide the data and session fT") 
management signalling above the LLC protocol layer. The solution in this 
case is to capture simultaneous trace over the Gr interface, look up the user 
specific Kc encryption key in the Gr trace and use the standardised 
encryption algorithms to decrypt the Gb traffic [Security]. After decryption, the... 
process is identical to the one described in previous section. The process is ( ... ) 
outlined in Figure 3. 
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Figure 3. Building the GPRS Traffic Database from an Encrypted Gb and a Gr Trace 
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Building the traffic database from an encrypted Gb and a Gn trace 

If the Gb trace is encrypted, it is encrypted at the LLC layer. This means that 
mobility management information can still be obtained from the BSSGP 
protocol header. The PDP session control signalling messages are present in 
the Gn trace together with all the user data packets. !P packets of the user 
data are extracted from the GTP tunnelling packets, and not from the BSSGP 
UNITDATA packets. The process is depicted in Figure 4. 
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Figure 4. Building the traffic database from an encrypted Gb and Gn trace 



Building the traffic database from an encrypted Gb, Gi, RADIUS trace 

It is possible to use Gi traces provided that the Gi trace is amended with the 
RADIUS packets. Further requirement is that the optional, vendor specific 
parameter IMSI is present in the RADIUS messages [RADIUS]. A RADIUS 
request will indicate the start of a PDP session and trigger the construction of 
a new session record. The user will be identified in the RADIUS packets by 
the IMSI therefore the mobility pattern found in the Gb trace can be 
associated with the user sessions and transactions found in the Gi/RADIUS 
trace. 
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Building the traffic database from an encrypted Gb, Gi, RADIUS trace 
and an {MSISDN,IMSI} list 




It is possible to use Gi traces provided that the Gi trace is amended with the 
RADIUS packets (No optional (MSI in RADIUS packets!), and there is a 
database containing the list of {IMSI,MSISDN} pairings for the users. A 
RADIUS request will indicate the start of a PDP session and trigger the 
construction of a new session record. The user will be identified in the 
RADIUS packets by an MSISDN. To be able to associate the mobility pattern 
found in the Gb trace with the user sessions and transactions the 
corresponding IMSI needs to be looked up in the {IMSI, MSISDN} database. 
This option is depicted in Figure 5. 
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Figure 5. Building the traffic database from an encrypted Gb, Gi, RADIUS trace and an {MSISDNJMSI} list 



Building the traffic database from an encrypted Gb, Gi, RADIUS trace 
and a fractional Gn trace 



If there is any sort of Gn trace available, not necessarily simultaneous with 
the Gb and Gi trace, but covering the same network segment, it can be used 
to automatically build a large enough database of {IMSI, MSISDN} pairs: 
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• If GTP version used over the Gn interface is vO, the IMS! is contained 
in every message header as part of the Tunnel ID filed, while the 
MSISDN is present as a mandatory parameter in Create PDP Context 
Request messages. 

• If GTP version used over the Gn interface is v1 , both the IMS! and the 
MSISDN is contained as a conditiona! parameter in Create PDP 
Context Request messages. 

Using this list of {IMSI, MSISDN} pairs, the procedure of the previous section 
can be applied. This alternative is depicted in Figure 6. 
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Figure 6. Building the traffic database from an encrypted Gb 3 Gi, RADIUS trace and a fractional Gn trace 
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4.1.3 



Defining the set of key performance indicators 



The key performance indicators listed in Section 4.1.1.3 are suitable for the 
specific case of GPRS networks. 



The process described in Section 4.1.1.4 can be used for calculating the key 
performance indicators from the GPRS traffic databases. 



A method for passive measurement based characterization of mobile packet 
data networks is proposed which makes possible for the operator to obtain 
key performance indicators to describe the user perceived end to end 
performance of different applications, and the measurement results are 
associated with specific cells. The proposed method therefore not just 
indicates a performance problem but also pinpoints the location of the 
problem. 

The proposed solution uses raw measurement data available from 
standardized network interfaces which has two important advantages: 

1 . vendor independent 

2, easy to obtain enough measurement data to calculate results with 
statistical significance 

Cellular mobile packet data operators when trying to increase the revenue 
they obtain from packet switched services face a significant challenge. They 
need to attract business users to cash in a big amount of money, but 
business users require a robust, reliable service, which offers quality of 
service guarantees. One way to overcome this problem is to define a service 
level agreement, which outlines what sort of guarantees the subscriber can 
expect from the network. For such an agreement to be convincing for the 
potential customers, it shall be written in terms of the user perceived 
performance indicators. The monitoring method described in this document is 
a tool for the operator to offer such new, value added services, because it 
gives a cheap, easy to implement way of monitoring and tracking the 
guarantees put forward in such a service level agreement. 

The solution readily lends itself for application in GPRS, which is the most 
widely used mobile packet data network technology today. A preferred 
implementation of the solution in GPRS networks is also detailed. 

The database used by the GPRS specific embodiment of this invention differs 
from the database proposed in [GPRS__meas] in the following significant 
ways: 

• A field is added to each transaction record showing the identifier of 
the cell, which the transaction commenced in. 



4.1.4 



Calculating the value of the key performance indicators 



4.2 



Advantages of the Invention 
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• A field is added to each transaction record showing a binary value 
indicating whether cell change has happened during the transaction. 

• A field is added to each transaction record showing the multislot class 
capability of the terminal, which carried out the transaction. 

• A field is added to each transaction record containing the I MSI of the 
subscriber, who carried out the transaction. 

• A field is added to each user session record containing the I MSI of the 
subscriber, who the user session belongs to. 

• A variable length field is added to each user session record showing 
the list of {cell identifier, timestamp} pairs for each cell change, which 
occurred during the user session. 

Further advantage of the method is that it does not rely on a particular trace 
when constructing the traffic database but it is capable of obtaining and 
correlating the required information from a set of different trace combinations 
of standardized Gb, Gi, Gn, and Gr GPRS interfaces. This makes the method 
applicable for most of GPRS networks which are run today regardless of their 
safient configuration settings. 

Abbreviations 



BSC 


Base Station Controller 


BBS 


Base Station System 


BSSGP 


BSS GPRS Protocol 


CDMA 


Code Division Multiple Access 


DNS 


Domain Name System 


FTP 


File Transfer Protocol 


GGSN 


Gateway GPRS Support Node 


GPRS 


General Packet Radio Service 


GTP 


GPRS Tunneling Protocol 


HLR 


Home Location Register 


HTTP 


Hypertext Transfer Protocol 


IE 


Information Element 


IP 


Internet Protocol 


IMSI 


International Mobile Subscriber Identity 


ISP 


Internet Service Provider 


KPI 


Key Performance Indicator 


LLC 


Logical Link Control 


MMS 


Multimedia Message Service 


MS 


Mobile Station 


PCU 


Packet Control Unit 


PDCH 


Packet Data Channel 


PDP 


Packet Data Protocol 


PDU 


Protocol Data Unit 


POP 


Post Office Protocol 


QoS 


Quality of Service 


RADIUS 


Remote Authentication Dial-In User Service 


RLC 


Radio Link Control 


SGSN 


Serving GPRS Support Node 
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STS Statistics and Traffic Measurement Subsystem 

TCH Traffic Channel 

TCP Transmission Control Protocol 

TLLi Temporary Logical Link Identity 

TRU Transciever Unft 

UMTS Universal Mobile Telecommunication Service 

UDP User Datagram Protocol 

WAP Wireless Application Protocol 
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Invention Information 

7:1 Do you know of any publication dates/deadlines for this invention? 

□ No • Yes, specify 

• Date of Publication: 2003-09-01 

• Type of Publication: 

o Commercial sale or use? 
o Marketing exercises? 



. research co-operation with Vbdafone Group R&p' - " 



o Standard? 
o Other? 

7:2 Do you know the name(s) of any Ericsson expert in this field? 

P No. • Yes, specify 

• Name the expert(s): Martin SkarVe, GEC Sweden; Erik Westerberg, 
CRND; Jonas Backman, Global Services 

7:3 Origin of your invention 

The inventors work in the 'Traffic analysis in GPRS/EDGE and UMTS 
network" research area of Traffic Lab, One important goal of this research , --^ 
area is to devise efficient and precise characterisation methods for the 
performance management of packet switched mobile data networks. 

An earlier patent application covers the architecture and main functionality of 
the Moniq ( http ://www.r eth . ericsson . se/ RB/moniq/) tool. f '\ 

This invention disclosure is the first full description of the invention. 

The invention is related to the MAGNeD project 

(http://www.r.eth.ericsson.se/RL/magned/), which is a joint research project of 
Vodafone and Ericsson, but can definitely not be regarded as a result of this 
project. MAGNeD is funded by Ericsson Research, project co-ordinator from 
Ericsson is Istvan Szabo. 

7:4 Will this invention be incorporated into an existing/future product? 

□ No ♦ Yes, specify 

• Name the product: Moniq 
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Moniq is a passive software tool providing end-to-end performance indicators 
and traffic statistics from monitoring subscriber traffic in mobile data 
networks. 



• Potential customers or markets: Basically every mobile operator either by 
buying the tool developed based on this methodology or by buying a 
network improvement service, which uses the proposed methodology. 

• Is this a product in an evolving market? Yes, passive measurement based 
network analysis becomes more and more popular among operators. 

7:5 Is this invention related to any technology governed by a particular 
governing body including standards? 

D No • Yes, specify 

• The name of the standard: 3GPP, 3GPP2 standards describing 2.5 and 
3G mobile data networks 



• is the invention related to the implementation of the standard? No, the 
invention is related to the performance monitoring of networks built based 
on these standards 

• Is the invention compulsory or optional to the standard? No 

• Will Ericsson submit a contribution for this invention? Not likely 
7:6 Can your invention be detected when it is implemented? 

□ No • Yes, specify 

• How can it be detected? Anybody claiming to building a mobility aware 
condensed database of user sessions and transactions from raw data 
captured over standardised interfaces would infringe this invention. 

• Does this require much effort? Medium Effort 

7:7 Do you know the names of any of Ericsson competitors in the area 
of your invention? 

• No □ Yes, specify 

• Name the competitor(s): 
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